Skip to content

Discover scalar composite features in Home Assistant#32363

Draft
MaxRink wants to merge 6 commits into
Koenkk:devfrom
MaxRink:ha-discovery-composite-features
Draft

Discover scalar composite features in Home Assistant#32363
MaxRink wants to merge 6 commits into
Koenkk:devfrom
MaxRink:ha-discovery-composite-features

Conversation

@MaxRink

@MaxRink MaxRink commented Jun 21, 2026 •
edited
Loading

Copy link
Copy Markdown

Design outcome

This remains draft intentionally.

Reviewer feedback pointed out that broad scalar-composite discovery is the wrong default when a converter can expose independent values directly. The SONOFF valve work moved the affected irrigation/manual-watering values to scalar exposes in zigbee-herdsman-converters, which is the cleaner design and avoids Home Assistant discovery guessing intent from composite children.

Current scope if this is revived

  • only expose scalar composite children for a concrete device/use case that cannot be represented cleanly in the converter
  • do not split composite values that are atomic and must be written as one object
  • keep converter-provided metadata as the source of truth instead of adding Home Assistant-specific inference

Home Assistant limitation

MQTT discovery can set entity_category and enabled_by_default, but it cannot create arbitrary custom sections on a device page or attach sibling entities to a valve more-info dialog. Grouped irrigation/manual-control UI still needs a dashboard/card or future Home Assistant support.

Status

Kept as draft, not ready for merge. The practical path is to continue fixing over-used composites in zigbee-herdsman-converters first, then revisit this only if a clear generic gap remains.

@MaxRink MaxRink force-pushed the ha-discovery-composite-features branch 2 times, most recently from 9bc2097 to 5f6341a Compare June 21, 2026 22:25
@MaxRink

MaxRink commented Jun 22, 2026 •
edited
Loading

Copy link
Copy Markdown
Author

Superseded by the current live validation notes in the PR description.

@MaxRink MaxRink force-pushed the ha-discovery-composite-features branch 2 times, most recently from 83f963b to dfc285f Compare June 22, 2026 10:12
@Koenkk

Koenkk commented Jun 22, 2026

Copy link
Copy Markdown
Owner

I think this is similar to #32362 (comment), maybe we should change the device expose instead? I think we over-used composite a bit. It should only be used for cases were e.g. 2 properties always need to be set together, and I don't think HA supports that (e.g. image a config for a window cover where both left and right calibration position have to be set together, in 1 message send to the device).

@MaxRink MaxRink force-pushed the ha-discovery-composite-features branch from dfc285f to 27217e5 Compare June 22, 2026 19:44
@MaxRink

MaxRink commented Jun 22, 2026

Copy link
Copy Markdown
Author

Agreed on the distinction. This PR is scoped to safe scalar composite children only; atomic composite controls that need one object payload should stay composite or be represented differently in the converter.

The water-valve work also has a converter-side split where possible, so this generic path is for the remaining cases where scalar config/diagnostic values are still nested inside a composite.

This was referenced Jun 23, 2026
Merged
Open
@MaxRink MaxRink marked this pull request as draft June 23, 2026 10:43
@MaxRink MaxRink force-pushed the ha-discovery-composite-features branch from 1ffc261 to b6fb937 Compare June 23, 2026 18:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@MaxRink @Koenkk